home *** CD-ROM | disk | FTP | other *** search
/ Columbia Kermit / kermit.zip / newsgroups / misc.19980901-19981211 / 000089_news@newsmaster….columbia.edu _Thu Oct 1 09:54:38 1998.msg < prev    next >
Internet Message Format  |  2020-01-01  |  4KB
  1. Return-Path: <news@newsmaster.cc.columbia.edu>
  2. Received: from newsmaster.cc.columbia.edu (newsmaster.cc.columbia.edu [128.59.35.30])
  3.     by watsun.cc.columbia.edu (8.8.5/8.8.5) with ESMTP id JAA18170
  4.     for <kermit.misc@watsun.cc.columbia.edu>; Thu, 1 Oct 1998 09:54:38 -0400 (EDT)
  5. Received: (from news@localhost)
  6.     by newsmaster.cc.columbia.edu (8.8.5/8.8.5) id JAA03725
  7.     for kermit.misc@watsun; Thu, 1 Oct 1998 09:54:35 -0400 (EDT)
  8. Path: news.columbia.edu!watsun.cc.columbia.edu!fdc
  9. From: fdc@watsun.cc.columbia.edu (Frank da Cruz)
  10. Newsgroups: comp.protocols.kermit.misc
  11. Subject: Re: Telnet disconnect
  12. Date: 1 Oct 1998 13:54:31 GMT
  13. Organization: Columbia University
  14. Lines: 53
  15. Message-ID: <6v01in$qtb$1@apakabar.cc.columbia.edu>
  16. References: <F04wA5.DqL@cix.compulink.co.uk>
  17. NNTP-Posting-Host: watsun.cc.columbia.edu
  18. Xref: news.columbia.edu comp.protocols.kermit.misc:9272
  19.  
  20. In article <F04wA5.DqL@cix.compulink.co.uk>,
  21. Lygo Systems <lsystemsd@cix.compulink.co.uk> wrote:
  22. : Telnet disconnection due to reboot.
  23. : 
  24. : I have a number of users connecting with MS-DOS Kermit telnet sessions 
  25. : into Redhat Linux (4.2 & 5.1).  If they close the connection with the 
  26. : normal Kermit exit command without first logging off, then the telnet 
  27. : session is closed on Linux which is just what I want.  If, however, they 
  28. : reboot their PC with ALT CTL DEL then the session stays active.
  29. : 
  30. : The reason that this is a problem is that they are running the Pick/D3 
  31. : database which has a limited number of active users allowed to be logged 
  32. : on at the same time.  If they reboot their PC then that will effectively 
  33. : lose one user unless the previous session is automatically logged off.  
  34. : Pick has a couple of commands that in theory should deal with the 
  35. : situation: DCD-ON and TRAP DCD EXIT.  In other words if DCD is lost then 
  36. : the session should be automatically closed.  But it ain't happening...
  37. : 
  38. By design, it is not possible for the application on one end of a TCP/IP
  39. connection to detect that the connection is broken, except by trying to send
  40. data on the connection (as Jeff pointed out).  Remember, TCP/IP is not a
  41. point-to-point connection like you get with a modem (which has a constant,
  42. out-of-band carrier signal that gives the status of the connection), nor is
  43. it a virtual circuit as in X.25.  In fact, IP packets are datagrams that can
  44. arrive (or not) from any direction at any time at all.  Datagrams are a
  45. feature of a connectionless protocol, which, in a sense, means there is no
  46. connection at the IP level.
  47.  
  48. There is a little-used keepalive mechanism at the TCP level to allow the end
  49. partners of a TCP session to detect when there has been no activity for a
  50. certain amount of time, but even when it is used, the timeout is generally
  51. set an an hour or more.
  52.  
  53. In general, it is each application's responsibility to monitor the
  54. connection in some application-specific way.  For example, a UNIX login
  55. shell might time out and exit if there has been no i/o for (say) 20 minutes.
  56. However, applications like Telnet do not include any *active* form of
  57. monitoring.  If the server disappears, the client never finds out until the
  58. user presses a key (which causes an i/o attempt on the broken session).  But
  59. if the client disappears, there is no user on the server end to press a key,
  60. so the server might easily wait forever for the next message from the
  61. client.
  62.  
  63. When Kermit is told to exit, it closes any open connections.  But obviously,
  64. if a PC is turned off, or crashes, neither Kermit nor the underlying TCP/IP
  65. stack have any way to send close messages, and so any connection partners
  66. are left waiting for an indeterminate amount of time for IP packets to
  67. arrive from the great beyond.
  68.  
  69. I think you will see the same behavior no matter what Telnet client you use.
  70. It's not a Kermit problem; it's a TCP/IP protocol feature.
  71.  
  72. - Frank